Terraform StacksのOrchestration rulesを試してみた

Terraform StacksのDeploymentsを管理できるOrchestration rulesについて試してみました。

Terraform Stacksとは

Terraform Stacksは、複数環境・複数リージョン(複数Statefile)を使った構成を効率的に管理できる機能です。

本記事執筆時点(2024/11)では、パブリックベータです。

https://dev.classmethod.jp/articles/terraform-stacks-started-hashitalks-2024/

https://dev.classmethod.jp/articles/terraform-stacks-illustration/

Orchestration rulesとは

Terraform Stacksに、Orchestration rulesという機能があります。

この機能を使うと、Deploymentsを管理するルールを作成できます。

現時点では以下の2種類のルールを作ることができます。

例えば、本番環境のDeploymentsは手動承認必須・その他環境は自動承認といったルールを作成できます。

https://developer.hashicorp.com/terraform/language/stacks/deploy/conditions

Orchestration rulesの作り方

*.tfdeploy.hclファイルに、orchestrateブロックを使って記述します。

ルールはcheckブロックを使って定義します。

# 本番環境以外の環境を自動承認
orchestrate "auto_approve" "no_prod" {
  check {
    condition = context.plan.deployment != deployment.prod
    reason    = "Not automatically approved prod."
  }
}

context変数に含まれるフィールド等は以下で確認できます。

https://developer.hashicorp.com/terraform/language/stacks/reference/tfdeploy#complete-configuration-1

ルールを作ってみる

開発環境のPlanを自動承認

orchestrate "auto_approve" "dev" {
  check {
    condition = context.plan.deployment == deployment.dev
    reason    = "Automatically approved dev."
  }
}

分かりやすくていいですが、自動承認の対象環境が増えるとcheckブロックかorchestrateブロックを増やす必要があります。

次に紹介するルールのほうがより実践的です。

ちなみに、auto_approveの適用はPlan結果の「Timeline」上で確認できます。

非本番環境でリソースを削除しないプランを自動承認

「開発環境のPlanを自動承認」の応用版です。

上記の公式ドキュメント内でも紹介されているルールです。

1つ目のcheckブロックでPlanに削除が含まれていないことを、2つ目で非本番環境であることを判定しています。

orchestrate "auto_approve" "safe_plans" {
    # Ensure that no resource is removed.
    check {
        condition = context.plan.changes.remove == 0
        reason    = "Plan is destroying ${context.plan.changes.remove} resources."
    }

    # Ensure that the deployment is not your production environment.
    check {
        condition = context.plan.deployment != deployment.production
        reason    = "Production plans are not eligible for auto_approve."
    }
}

Apply後にPlanを自動で実行

Apply後、確認のためにPlanを再実行することがあると思います。

replanリソースを使って、以下のように定義できます。

orchestrate "replan" "verification" {
    check {
        condition = context.operation == "apply"
        reason = "Post-apply verification replan"
    }
}

replanルールによるPlanかは、Planの画面上から確認できます。

変更なしでも、手動承認ありだと「waiting」のステータスになるため、変更無しの場合は自動承認する「auto_approve」のルールと組み合わせたほうが良いかもしれません。(手動承認してもOK)

補足:

Deferred Changeで遅延させたPlanを再実行してみようと思いましたが、Plan適用時に遅延したPlanが実行されたので不要でした。

おわりに

Orchestration rulesについてでした。

Workspacesで環境ごとにApplyトリガーの設定を行う場合、GUIまたはtfe providerを使う必要があります。

Terraform Stacksでは、*.tfdeploy.hclに書くだけののため、設定が簡単でした。

以上、AWS事業本部の佐藤(@chari7311)でした。